fix: set cache control for only _next folder #851
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Datadog ReportBranch report: ✅ 0 Failed, 166 Passed, 34 Skipped, 34.34s Total Time |
| @@ -119,6 +124,3 @@ echo "ETag: $ETag" | |||
| jq '.Distribution.DistributionConfig' distribution.json > distribution-new.json | |||
| jq ".Origins.Items[0].OriginPath = \"/$SITE_NAME/$CODEBUILD_BUILD_NUMBER/latest\"" distribution-new.json > distribution-config.json | |||
| aws cloudfront update-distribution --id $CLOUDFRONT_DISTRIBUTION_ID --distribution-config file://distribution-config.json --if-match $ETag | |||
|
|
|||
| # Invalidate CloudFront cache | |||
There was a problem hiding this comment.
if you don't invalidate, the max time for a change to be live is 30 mins of build + 10 mins of previous cache = 40 mins right
I think we should still invalidate the cache, but having the TTL longer for _next helps to solve for those weird edge cases where the old versions of the HTMLs are being loaded and is unable to find the right _next chunk
There was a problem hiding this comment.
Hmm no, we can't invalidate because it is the CloudFront invalidation process that is opaque to us and caused us some issues. If we perform the invalidation, then the cached file in CloudFront gets removed, which then causes the 404 errors for the chunks that we were seeing earlier. We still want the old cached file in CloudFront to be retained so that in case users are still seeing the old index.html file which references these old chunks, they don't receive a 404.
There was a problem hiding this comment.
okay so what is the maximum time for a change to be live to MOPs now? is 10 mins + build time right?
If builds are still around 20-30 mins + 10mins, I think we still need to optimise this to be faster, but can be a future improvement
There was a problem hiding this comment.
Yeah in the worst case would be 10 minutes + build times but I think we should accept this because otherwise we lose the benefits of having CloudFront provide the caching for us, which can affect our time to first byte.
Problem
We currently do a complete invalidation on CloudFront, which has some race condition issues and causes visitors to encounter an irresponsive website.
Solution
Breaking Changes
Bug Fixes:
_nextfolder has a much longer cache duration of 24 hours.